With the growing popularity of the Internet and the World Wide Web, the volume of traffic over networks has substantially increased. As a result, the need for maintaining an efficient flow of information over data communication networks has become increasingly important. Due to the inherent limitations of network infrastructures, network bandwidth (a measure of the capacity of a communications channel) is limited. Network providers pay for network utilization, and, consequently, pass at least some of these costs on to their subscribers. Typically, subscribers of network services utilize a myriad of applications and receive a variety of services over networks. For example, subscribers may run real-time applications such as, but not limited to, Video On Demand (VOD), Voice over Internet Protocol (VoIP), Walled Garden, Premium Data, and etc. VOD is a technology where users can demand a selected video, such as a movie, be played over the network. Similarly, VoIP is a technology used to transmit voice conversations over a data networks using an Internet Protocol. These technologies require a router or other network element to provide the services to subscribers over a network, such as a data network. Typically, real-time applications such as VOD and VoIP involve transmitting and receiving IP packets that require relatively large bandwidth, short latency jitter, and a reasonably small data loss ratio.
Often subscribers want a certain bandwidth and connection rate to run their applications. In order to guarantee a certain connection and data rate, service providers provide levels of “Quality of Service” (QoS) which is a generic term used for expressing the measuring and maintaining of the quality of a network channel. QoS involves the idea that transmission rates, error rates, and other characteristics of quality of a network can be measured, improved, and, to some extent, guaranteed in advance. One problem that has arisen is that, since service providers charge a fee for bandwidth utilization, subscribers often pay different amounts for different levels or classes of services. Providing accounting for these different levels of QoS for each subscriber can often lead to difficult and complex problems configuring and managing both the services themselves as well as the accounting for those services for each subscriber.
One solution has been to establish support for services and accounting for services within the network element (e.g., a bridge or router) that receives individual subscriber records containing information for each subscriber from a remote server (e.g., through remote authentication dial-in user service or Radius). To do this requires configuring a set of internal network attributes within the network element to provide support for services and accounting for services. These internal network element attributes include such things as port descriptions, network interfaces, data rate, volume limit, other traffic policies, and so on. The network attributes are used for configuring the network element for services and accounting for services. As such, these attributes are subscriber-specific depending on the subscriber's level of service, and must be configured on a per-subscriber basis. Unfortunately, as the number and types of services has increased over time, so has the number and complexity of the network attributes that must be configured within the network element. Thus, service management has become a difficult task because of the complex internal network element attributes required to configure services and accounting for services for each subscriber. Additionally, the attributes are exposed to network server administrators who must manage the associated subscriber databases at the server. As a result, administrators have to understand the complex internal attributes of the network element as well as all the interdependencies between the complex internal attributes to properly configure services and accounting for services for each subscriber on the network element. This problem is compounded when a subscriber requires a change in services or deactivation of services. Change of services and/or deactivation of services involves the update to numerous internal attributes and their interdependent attributes. This component is increasingly complex and prone to human error.
Additionally, the server must store all the internal network element attributes and must pass them to the network element using messaging over the network. Consequently, the size and frequency of messages that must be passed between the server and the network element which manages subscriber access to services is becoming increasingly large and the processing logic is becoming increasingly complex.
For example, FIG. 1A illustrates an exemplary network element communicating subscriber-specific services information with a server using complex internal network attributes according to the prior art. FIG. 1A includes network element 101, subscribers 135 and Radius server 125. Network element 101 further includes packet processors 111-114 and control card 123. Control card 123 includes feature managers 140 including back-end components QoS 141 and CLS 143 running within control card 123. Back-end components such as QoS 141 and CLS 143 perform, among other things, the “Quality of Service” and other IP policy filtering of network traffic. Control card 123 further includes authentication, authorization, and accounting (AAA) component 122 which contains local configuration files, including local config file_0 150 and local config file_1 151. These local configuration files contain, among other things, the set of network element internal attributes for configuring the services and accounting for services for each subscriber on network element 101. For example, local config file_0 150 includes local per-subscriber memory 155. Local per-subscriber memory 155 includes complex internal attributes which are used to configure services and accounting for services on network element 101 for the particular subscriber corresponding to local config_0 file 150. Each of these complex internal attributes could include, for example, port descriptions, network interfaces, or other traffic policies, and are used for configuring services on a network element for associated subscribers.
In order to configure the network to support services and accounting for services, Radius server 125 sends a set of complex Radius service attributes 126 contained within a subscriber record of subscriber records 129 corresponding to the subscriber who requires activation and/or deactivation of services. For example, there may be an activation or deactivation request initiated by the subscriber that causes the network to be reconfigured for that particular subscriber. In such a case, the subscriber's records located in subscriber records 129 are updated and sent as Radius service attributes 126 to the network element so that the services can be configured/re-configured. These Radius service attributes 126 are received at AAA component 122 and stored into the local per-subscriber memory 155 corresponding to the local configuration file, local config file_0 associated with the subscriber requiring a change of services.
The Radius service attributes 126 are the same attributes as the complex internal attributes stored in the local per-subscriber memory 155 for each subscriber. That is, the Radius service attributes 126 are copied directly from subscriber records 129 and stored into the local per-subscriber memory 155 of local config file_0. The Radius service attributes 126 are complex subscriber-specific attributes to configure services within network element 101. These are the internal attributes required to provide the level of services for the corresponding subscriber on the network. However, as discussed above, when the level and quantity of services offered by service providers increases, so does the amount and complexity of these internal network element attributes contained within the attribute list maintained within AAA component 122. These complex attributes must be configured by administrators (not shown) at Radius server 125. Radius server 125 includes a set of subscriber records 129 corresponding to each subscriber currently subscribed to the network. Subscriber records 129 include various strings used by network administrators to configure the services and accounting for services in network element 101. For example, subscriber records 129 includes strings of attribute names and attribute values such as IP-filter, rate limit, and many others including vendor specific attributes. In order to provide support for services and accounting for services, the administrators at server 125 must configure subscriber records 129 to provide the appropriate internal attributes to the network element such as network element 101. As a result, the administrators must be well-versed in the internal attributes of the network element. Moreover, when a subscriber changes his or her service level or requests additional or different services, subscriber records 129 must be re-configured. As discussed above, the complexity and interdependency of configuring subscriber services and accounting for services in this way is inefficient and prone to human error.